add proposal for k1-for-devs #1757
Conversation
|
@stroebitzer: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
kubermatic-bot
added
dco-signoff: yes
|
/assign @scheeles |
kubermatic-bot
added
size/L
kubermatic-bot
added
size/M
| ### GitOps | ||
| * FluxCD and/or ArgoCD should get supported. They should become its own KubeOne AddOn. Their controllers should get installed into the KubeOne cluster. We should take care that the Git Repo holding the yaml files for the Kubernetes Cluster can be configured easily. | ||
|
|
||
| ### Vault |
There was a problem hiding this comment.
I would consider Vault for a later stage.
There was a problem hiding this comment.
TBH, I wouldn't consider Vault at all. Vault is in fact a very complex component if you want to set it up in a proper way. You mostly like want to integrate with your cloud provider KMS solution, secure your keys, etc... Abstracting that away from the user can create a huge security hole.
| * Theia is a nodejs application which provides the IDE. Workspace management has to be provided by Eclipse Che. | ||
| * Eclipse Che is holding all the workspace data and all user-specific file-based configurations, eg the .gitconfig | ||
|
|
||
| ### Terminal integrations |
There was a problem hiding this comment.
I would add tilt https://github.com/tilt-dev/tilt so that you constantly deploy the code to the cluster
There was a problem hiding this comment.
@archups @nerdeveloper can you please take a look at it and give some info about your experiences
There was a problem hiding this comment.
I have heard about it, I am not entirely sure if tilt and entando do the same thing. I could take tilt for a spin and check the developer experience.
| * Dex as IDP with Github | ||
|
|
||
| ### Visualization of the Kubernetes Cluster | ||
| * Either via enabling the Kubernetes Dashboard or via the [VSCode Kubernetes AddOn](https://marketplace.visualstudio.com/items?itemName=ms-kubernetes-tools.vscode-kubernetes-tools) (if that is doable in Theia) |
| ## Implementation | ||
|
|
||
| ### IDE | ||
| * Using [Eclipse Che](https://github.com/eclipse/che) as Cloud IDE. Eclipse Che is a workspace server integrating Theia as a default. |
There was a problem hiding this comment.
Let try the devworkspace https://www.eclipse.org/che/docs/che-7/administration-guide/architecture-overview-with-devworkspace/ as it uses more the K8s API and is the future of Che eclipse-che/che#20830
|
|
||
| ### IDE | ||
| * Using [Eclipse Che](https://github.com/eclipse/che) as Cloud IDE. Eclipse Che is a workspace server integrating Theia as a default. | ||
| * Theia is a nodejs application which provides the IDE. Workspace management has to be provided by Eclipse Che. |
There was a problem hiding this comment.
For the future, I think we should consider VS Code as the default but still need some development eclipse-che/che#20500
There was a problem hiding this comment.
Yes we should definitely consider something different than Theia. I had bad experiences with it due to nodejs dependency hell.
| @@ -0,0 +1,76 @@ | |||
| # KubeOne for Developers | |||
There was a problem hiding this comment.
This proposal is missing some key sections:
- Values and alternatives -- the key question I'd like to see answered is why would someone want to use this over GitPod and GitHub Codespaces? Those two products are also cheaper than a Kubernetes cluster created by KubeOne on any cloud provider, so there's that too.
- Ownership -- who is going to own and maintain the project?
- Location -- where is this addon going to live? This depends on the ownership question as well. If this is to be maintained by a dedicated team then it should live in another repo.
In my opinion, everyone should be able to use KubeOne as a building block. In that aspect, I'd like this proposal to focus on what we can do to make implementing this possible. I see two key aspects:
- Improving usability and the infrastructure management experience
- Improving the addons mechanism
If that's the case, I'd like to see what we can do to improve those two aspects.
There was a problem hiding this comment.
Values and alternatives Yes, I think we should spent some time looking for alternatives on the market before starting implementation. Concerning GitPod and CodeSpaces: I am not sure if those are usable on private clusters. Those tools are running on some GitHub infra and not in a dedicated cluster. IMO the idea is to add functionality to clusters created via KubeOne. Which you may can do with GitPod and CodeSpaces via connecting them to your Kubernetes Cluster but this will not be doable all the time (private clusters) and also has some security implications.
Ownership & Location Good question, we should discuss this, maybe @scheeles has some input here
|
|
||
| ## Goals | ||
| * "Developer Batteries included" | ||
| * Developers should get enabled to start working on the Kubernetes Cluster without having to deal with infrastructure setup problems |
There was a problem hiding this comment.
This is unclear and should be clarified.
It's just impossible to get a cluster on any cloud provider without infrastructure setup problems. You at least have to create an account, and in many cases, set up your account, configure billing, configure initial subnets and network gateways (especially on AWS), etc...
Therefore, what are the problems that we should solve?
There was a problem hiding this comment.
I think this is a different problem you are talking. Yes, you are right you need that stuff to get your cluster via KubeOne up and running.
The problem which we want to solve with this proposal is more about: OK, now I have my running cluster via KubeOne, what do I need to do to have a cool developer experience on it. By developer I mean the "enduser-developer", the one writing apps on the already existing Kubernetes Cluster.
| ### GitOps | ||
| * FluxCD and/or ArgoCD should get supported. They should become its own KubeOne AddOn. Their controllers should get installed into the KubeOne cluster. We should take care that the Git Repo holding the yaml files for the Kubernetes Cluster can be configured easily. | ||
|
|
||
| ### Vault |
There was a problem hiding this comment.
TBH, I wouldn't consider Vault at all. Vault is in fact a very complex component if you want to set it up in a proper way. You mostly like want to integrate with your cloud provider KMS solution, secure your keys, etc... Abstracting that away from the user can create a huge security hole.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: stroebitzer The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kubermatic-bot
added
the
do-not-merge/needs-kind
xmudrii
added
the
kind/documentation
kubermatic-bot
removed
the
do-not-merge/needs-kind
|
Given that there's no activity on this PR for a long time, I'll go ahead and close it. Please feel free to reopen it or create a new one if you want to proceed with this proposal. |
|
@xmudrii: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What this PR does / why we need it:
Having a discussion base for the project
kubeone for devsWhich issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Special notes for your reviewer:
This is a rather quick draft missing a lot of technical details. It should be seen as a document to gather the requirements.
Does this PR introduce a user-facing change?: